home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0082.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  1.0 KB  |  31 lines
  1. Peter Svanberg <psv@nada.kth.se> writes:
  2. > Quoting:  John Gardiner Myers <jgm+@cmu.edu>
  3. > > a005 GET ADDRESS.*
  4. > > * OPTION ADDRESS.FRED.EMAIL "fflinstone@foo.bar.com"
  5. > 
  6. > Just a thought: Have you (not especially John) considered
  7. > non-[A-Z]-letters in the short-form name?
  8.  
  9. In short, yes.  I have considered it, it is a major problem with my
  10. example as written, and it is something I want to address.
  11.  
  12. Solutions I can think of:
  13.  
  14. * Remove the restriction that option names be atoms.
  15. * Require the client to map the short-form name to an atom.
  16. * Make the second component of the name a gensym, putting the
  17.   short-form name in the value.  (* OPTION ADDRESS.A0001.NICK "Fred")
  18.  
  19. None of these is particularly appealing.  I would be very grateful for
  20. any assistance from someone with experience in these matters.
  21.  
  22. > Wider thought: Have you considered non-[A-Z]-letters in _every_ string
  23. > which is the result of user input or mail contents?
  24.  
  25. I believe so, but could be wrong.  RFC 821 limitations aside, I think
  26. the only problematic character is NUL.
  27.  
  28.                 _.John
  29.  
  30.  
  31.